How to Report Bugs in LibreOffice
TDF LibreOffice Document Liberation Project Блоги сообщества Weblate Nextcloud Redmine Ask LibreOffice Пожертвования
Какое счастье, что вы пришли сюда. Вы собираетесь внести важный вклад в LibreOffice. Этот вклад тяжело переоценить. Хороший отчет об ошибке помогает разработчикам быстро устранить неисправность. Ниже вы найдете несколько рекомендаций, чтобы сделать этот процесс проще.
Перед тем как публиковать отчет об ошибках
Пожалуйста, убедитесь что это ошибка. Иногда, часто при миграции с одного пакета приложений на другой, пользователь не сразу может избавиться от старых привычек, и ему необходимо время, чтобы воспринять логику нового приложения. Если вам нужна помощь по использованию LibreOffice, не ленитесь читать документацию. Так же вы можете посмотреть раздел часто задаваемые вопросы. Если после этого у вас останутся вопросы, не стесняйтесь спрашивать:
- Англоязычные ресурсы:
| Канал связи | Альтернатива | Помощь |
|---|---|---|
| Почтовая рассылка User LibreOffice | Веб-шлюз почтовой рассылки: http://nabble.documentfoundation.org/QA-f3613148.html | Пожалуйста, подпишитесь на рассылку] перед тем как отправлять сообщение. |
| Ask LibreOffice | ||
| IRC-канал #libreoffice-qa | Веб-шлюз для IRC-канала #libreoffice-qa |
| Class of Bugs | Where to file the bug |
|---|---|
| LibreOffice Extensions | With the extension author |
| TDF/LibreOffice Infrastructure (websites, mailing lists, etc.) | Redmine |
| Building LibreOffice | Developer mailing list |
| LibreOffice Unit Tests | Developer mailing list |
| Words missing from dictionaries | To the dictionary maintainer or repository |
| Mistakes in translations | Reporting them in Bugzilla is allowed, but it is more efficient to add them as suggestions in Weblate (does not require registration) |
Отправка отчета об ошибке
Confirm that it really is a bug. Most of the time, a bug is something that makes the software behave in a way that a reasonable user would not want it to behave. This includes the software not doing what you want it to do, doing what you never asked it to do, or just plain crashing under normal use. Going behind the scenes, a bug may be something that causes the software to take a lot longer and use a lot more resources doing stuff than it should.
Важно: не включайте в один отчет об ошибках информацию о разных ошибках. Используйте принцип: одна ошибка — один отчет об ошибке.
Для отправки отчета об ошибке перейдите в помощник представления ошибки в Bugzilla.
Авторизация (Sign in)
Для того, чтобы отправить отчет об ошибке, вам необходимо иметь учетную запись на Bugzilla На первом шаге вам может быть предложено авторизироваться, используйте для этого свою учетную запись на bugs.documentfoundation.org.
But let’s say what you found really does look like a bug. Here’s what to do next:
- Take notes so you don’t forget something that was going on around the time the bug appeared. What were you doing, what did you expect to happen, and what actually happened? How did you know something was wrong? Can you reproduce the bad behavior?
- If possible, check for similar, existing bug reports (but avoid spending too much on it, and better file a dupe than give up):
- Go to Components, and select the appropriate component (or subcomponent).
- If you selected a component: select the appropriate subcomponent, or Extended Help if you don’t see the subcomponent on that page.
- If you selected Extended Help: select the appropriate subcomponent, or the [1] at the bottom of the list if you did not find or do not know the appropriate subcomponent.
- You will see a list of bugs with that subcomponent. At the bottom of the page, select Edit Search. There, you can modify the search according to your needs.
- If you find a bug report that concerns your problem, you can contribute to it. If you don’t find a bug report that concerns your problem, file a new bug report.
- If the bug only occurs on Ubuntu or is related to printing, go to #More Information.
- After all that, if it does not look like there is a bug report about this issue, follow the instructions at #Submitting a bug.
Submitting a bug
File a separate bug report for each bug you run into, even if the symptoms from a user’s point of view seem identical. Different problems with different roots that appeared in different LibO versions might have to be fixed by different people, for different versions, and at different times. It is impossible to track that in a single bug report.
Go to Bugzilla.
Sign in
If you are prompted to Log In, log in with your Bugzilla account.
If you don't have a Bugzilla account, create one by clicking New Account.
Компонент (Component)
В "Component" выберите необходимый компонент.
In Component, choose the component.
Если вы не уверены, что компонент связан с вашей проблемой, выберите как компонент Libreoffice. Кто-нибудь придёт и изменит позже. Но это может существенно замедлить исправление ошибки. По этому, постарайтесь, всё таки, определить компонент, с которым связана ошибка. (За большей информацией обратитесь к странице "Сортировка ошибок".)
If it is an urgent issue (broken parts, regression, etc.), and you are an experienced user who knows the development team, you can assign the bug report to one of the developers listed on the FindTheExpert page.
Детали (Details)
Если существует Sub component в этом компоненте, выберите субкомпонент.
If there is a Sub-component section, select the subcomponent.
Если вы не знаете соответствующий субкомпонент, смотрите страницу Компоненты. На этой странице выберите необходимый компонент. Прочтите описание всех субкомпонентов для этого компонента. Если после этого вы не можете определить необходимый субкомпонент, выберите Extended Help и прочтите подробное описание.
В поле Version выберите версию приложения в которой вы обнаружили эту ошибку. Посмотреть версию в LibreOffice можно в программе, пройдя в меню ▸ .
В поле OS выберите операционную систему, в которой была обнаружена ошибка.
На поле Hardware выберите в этом поле платформу вашего устройства.
Раздел Severity можно проигнорировать. Выбор Blocker не сделает решение проблемы более быстрым. Если вам интересно знать значения элементов этого списка, смотрите эту схему и критерии выпуска.
Описание (Description)
В поле Summary:
- Не включайте информацию из предыдущих полей.
- Включите в это поле название субкомпонента из Компонентов.
- Название субкомпонента указывайте в верхнем регистре.
- Если имя субкомпонента может быть спутано с частью слова (для примера, UI часть слова quit), заключите его в квадратные скобки ([UI]).
- Не используйте более двух субкомпонентов.
- Вы можете сочетать компоненты в поле Subject, но используйте названия субкомпонентов точно идентичные написанию(например, "WIKIHELP [UI] not available in all languages").
- Постарайтесь изложить проблему кратно, но точно.
- Плохой пример: "File is broken" ("Файл сломан")
- Хороший пример: "Menu File > Save as not available (greyed out)" ("Меню Файл -> Сохранить как... не доступен (отображается серым цветом")
- Избегайте коротких форм таких, как "doesn't" или "isn't". Такие формы затрудняют запросы для поиска по Summary. Вместо них используйте полные формы "does not" или "is not".
- Если отчет об ошибке связан с некорректным завершением приложения LibreOffice или оно перестаёт отвечать(зависает), добавьте слово CRASH в поле Summary - это позволяет проще отследить появление таких ошибок на Bugzilla.
В поле Possible Duplicates: (Возможные дубликаты) автоматически делается выборка похожих ошибок. Проверьте не указана ли ваша ошибка в этим списке. Дополнительно проверьте список в Таблице Дубликатов, чтобы не создавать дублирующий отчет об ошибке. (Если вы нашли отчет об ошибке с вашей проблемой, не создавайте нового. Просто оставьте комментарий с дополнительной информацией, в уже существующем.) В поле "Description" укажите полное описание проблемы.
- Используйте пронумерованный список для последовательности шагов.
- Объясните что вы сделали. Например, вместо того, чтобы писать: "Open document" ("Открыть документ"), опишите действия полностью: "In new empty LibO Spreadsheet document, use menu File > Open (LibO dialog) > file type "Text documents" > select attached sample document > double click" ("В новом пустом документе электронных таблиц LibreOffice, использовать меню Файл > Открыть (Диалог LibreOffice) > тип файла Текстовый документ > выберите прилагаемый текстовый документ > двойной щелчок по документу левой кнопкой мыши")
- Если используете заранее подготовленные пакеты для установки в Linux, не забудьте сказать точную версию пакетов согласно вашему пакетному менеджеру. Для Windows укажите полное имя файла программы установки и откуда он был вами скачан.
- Укажите информацию об установленной и используемой локализации (язык пользовательского интерфейса, язык документа). Это может оказаться полезным.
- Если вы используете 32-битную версию LibreOffice на 64-битной операционной системе, пожалуйста, не забудьте это указать.
- Если это не официальная сборка LibreOffice, укажите источник пакетов.
- Опишите ожидаемое и текущее поведение.
Вы можете также прикрепить к отчету скриншот, образец документа или лог работы с отладочными символами
.
- Если вы на скриншоте не пытаетесь показать особенности национальной локализации, создавайте скриншот находясь в английском интерфейсе. Перейти в английский интерфейс можно в ▸ ▸ ▸ в разделе Язык, Пользовательский интерфейс. После выбора языка потребуется перезагрузка приложения.
- Скриншоты можно сделать более информативными, добавив комментарии и выделив места, на которые вы хотите обратить внимание.
- Если вы хотите прикрепить более одного скриншота, соберите их в один документ, например, в формате PDF. Пожалуйста, не забудьте добавить комментарии к каждому скриншоту.
- Если вы хотите добавить более одного документа (например, скриншот и лог выполнения программы), соберите их в один архив (лучше, если это будет zip-формат) и уже этот архив прикрепляйте к сообщению.
- Если вам необходимо прикрепить файл большого размера (больше чем 1 MB) на Bugzilla, воспользуйтесь ownCloud.
You can ignore the section latest known-working version.
Subject
Check in possibly related Bugs table on the bug-reporting page and additionally in the Duplicates Table to see whether the problem really has not been reported yet.
In the Subject section (also known as the Summary):
- Do not include information already known from the fields.
- Include the names of subcomponents from Components.
- Make the subcomponents uppercase.
- If the subcomponent can be confused with parts of a word (for example, UI is part of the word quit), surround the subcomponent with square brackets.
- Use at most two subcomponents.
- Use subcomponents exactly as they appear in the list, but you may integrate them into the subject line sentence like “WIKIHELP [UI] not available in all languages”.
- Summarize the problem fairly precisely.
- bad example: “File is broken”
- better example: “Menu File > Save as not available (greyed out)”
- Avoid short forms like “doesn’t” or “isn’t” to ease queries for strings in the Summary; instead, use the full form, such as “does not” or “is not”.
- If the problem written in the report is that LibreOffice crashes or stops responding (“hangs”), add the word CRASH to the Summary, so that these bugs can be located and tracked easily.
Description and attachments
In the Long Description or Description section, give a lengthier, factual description of the problem:
- list the steps to reproduce the bug;
- use a numbered list; and
- state the exact method to make something happen. For example, instead of writing “Open document”, write instead “In new empty LibO Spreadsheet document, use menu File > Open (LibO dialog) > file type “Text documents” > select attached sample document > double click”.
If you’re using a pre-built LibreOffice on Linux, list the exact versions of LibreOffice packages in your package management system. If you’re using Windows, list the exact filename of the installer, and from where it was downloaded.
- Including information about installed and used localization (UI language, document language) might be useful.
- Include whether a 32-bit LibreOffice is used on a 64-bit (Linux) system.
- Include the package source if it’s not the official LibreOffice build.
Write the expected behavior and the actual behavior.
You can include an attachment, such as a screenshot or a sample document. The typical way to take a screenshot is to press the "Print Screen/PrtScn" button on your keyboard. Depending on your operating system, you might have to then open an image editing application (such as Paint on Windows) and do Edit - Paste in it.
- If you create screenshots, switch the language to English before making the screenshot. You can do so in ▸ ▸ ▸ .
- You can make screenshots more useful by adding comments and marking relevant areas with LibreOffice Draw.
- If you want to attach more than one screenshot, you should collect them all in one document (copy / paste to a LibreOffice Draw document) and attach as a PDF. Please add a short comment to each screenshot to tell what you want to demonstrate with it.
- If you attach a sample document that exhibits the bug you are reporting, please make the document as minimal as possible. For example, for Writer bugs, the document should ideally have just a single paragraph. To make it easy to find the text from your document in debug tracing, use some very easily recognizable text, like AAAAAAAAAA ₂ ZZZZZZZZZZ for a bug that is triggered by that character.
- It is preferable to upload attachments individually. However, if you want to attach more than half a dozen documents, create a .zip file containing all documents and attach that .zip.
- If your attachment is too big to be attached in Bugzilla (bigger than 1 MB) you can use the Experimental upload page.
Status
The only time you should change the status to NEW is, if someone already confirmed the bug elsewhere (Ask, mailing list, some forum). In these cases, provide a link to the discussion with the confirmation.
Отправка (Submit)
Нажмите Submit, и ваш отчет будет добавлен в базу данных Bugzilla.
Click Submit, and your report will be added to the Bugzilla database.
Если Bugzilla кажется сложной
Если система отслеживания ошибка Bugzilla кажется вам сложной, вы можете получить помощь по своей проблеме в
If the Bugzilla bug tracking system seems daunting or too hard to understand, you should post your problem here:
users@global.libreoffice.org списке рассылке пользовательской поддержки или на форуме русскоязычной поддержки.
Even if you post your problem on those channels, your goal should be to get a good bug report on bugzilla. These channels might help you with that. Note, that reporting problems on social media (Facebook, Twitter etc.) is not productive in general as it will rarely lead to a good bug report ending up in bugzilla (see also: 99 ways to ruin an open source project, top 5).
После отправки отчёта об ошибке
Если никто не рассмотрел ваш отчет в соответствующее время (24 часа для критических ошибок и 14 дней для остальных), обратитесь с просьбой к кому-нибудь ещё в рассылке users@global.libreoffice.org или на IRC-канале #libreoffice IRC:// воспроизвести вашу ошибку.
If nobody has reviewed your report within an appropriate time (24 hours for a critical bug, 14 days for an enhancement request), consider asking someone else to reproduce your bug report on the users@global.libreoffice.org mailing list or IRC channel #libreoffice IRC://.
Добавление комментариев к отчетам об ошибках
Есть несколько вещей, которые стоит сказать про комментарии к отчетам об ошибках:
- Пожалуйста, воздержитесь от комментариев типа "У меня тоже". Комментарии, не имеющие никакой дополнительной информации, чаще всего только мешают конструктивной работе. Исключением является ситуация с неподтверждёнными ошибками. В этом случае, пожалуйста, предоставьте шаги каким образом можно воспроизвести ошибку (или подтвердить данные оригинального репортера) и выставьте статус NEW, если он ещё не стоит. Заметьте, что если нет четких шагов воспроизведения ошибки, этот вопрос быстро вернётся в состояние требующего дополнительную информацию (NEEDINFO), так что найти хороший и простой сценарий воспроизведения ошибки имеет очень важное значение.
- Пожалуйста, воздержитесь от добавления комментариев типа "у нас есть 100 (1000, 100500) рабочих мест и только эта ошибка не позволяет нам мигрировать", так как они не содержат никакой дополнительной информации, необходимой для команды QA и разработчиков. Обратите внимание, что LibreOffice является OpenSource проектом и ваша помощь в решении проблем, которые имеют отношение к вашей конкретной ситуации, может только приветствоваться. Для помощи проекту вы можете сделать следующие вещи:
- Принять на службу и/или обучить своих собственных программистов работе в LibreOffice. Мы с удовольствием будем наставлять их при необходимости, смотри developer's pages.
- Найти разработчика или компанию для работы по конкретным вопросам, смотри сертифицированные разработчики.
- Если вы располагаете лишь не большими средствами, но хотели бы сотрудничать, координировать или объединить ваши ресурсы с другими для финансирования конкретных исправления или улучшения функциональности, свяжитесь, пожалуйста, с The Document Foundation.
- Avoid posting “me too” comments which contain no additionally useful information.
The exception to this is when you comment on a bug that has been UNCONFIRMED so far. In that case, please provide reproduction steps (or confirm the ones given by the original reporter) and move the issue to status NEW. Note that if there are no clear reproduction steps, the issue might quickly move back to NEEDINFO, so finding a good and simple reproduction scenario is essential. - Refrain from adding comments along the line of “we have 1000 seats here and only this bug prevents us from migrating”, as it contains no additional information relevant to QA or to the priority of the issue.
LibreOffice is open source and your help in fixing issues that are relevant to your particular situation is most welcome. You can:
- Employ and/or teach your own developers to work on LibreOffice. We are most happy to mentor them: see the developer’s pages.
- Fund individuals or companies to work on specific issues - see the list of certified developers.
- Contact The Document Foundation to help you if you have only a small amount of funding, and want to collaborate, coordinate or pool your resources with others in the same situation to fund specific fixes or enhancements.
Good Reports
Minimum requirements
- OS/LibreOffice version;
- enumerated reproducible steps;
- simple attachments where appropriate; and
- observed/expected results.
Good Examples
Examples of Less Good Reports
Reports can be less than ideal for a number of reasons. Below are some of the common problems:
Paragraphs of Text
Describing a bug report in paragraphs of text is one of the most common problems. Developers do not have the time to read paragraphs of text. Clear, succinct, enumerated steps are always better.
One Report, Five Bugs
One report should only have a single bug in it. Grouping bugs, or listing a whole list of issues with a single document, is utterly unhelpful. In order to find developers to tackle issues, it is best to give them a single issue to focus on. They are unlikely to take on a bug that has multiple issues listed
Missing Details/Steps
All bug reports should have at minimum:
- your Operating System and version of LibreOffice;
- clear reproducible steps;
- expected results;
- observed results; and
- a simple attachment where appropriate.
Adding Superfluous Information
Adding a lot of extra details that aren’t relevant is another common problem. Examples include:
- “this is a blocker”;
- a long list of reasons why it’s a blocker;
- “I can’t use LibreOffice because of this bug”;
- “LibreOffice sucks” (or any variation of that); and
- I’m going to start using your competitor unless you fix it.
Complex Attachments
Attachments should be as simple as possible. Take the time to prune your examples to the bare minimum. This helps tremendously in diagnosing problems.
Assuming Contributors Know Everything
Do not assume contributors know what you’re talking about. Describe your steps clearly, each step of the way.